Location-Aware Selection of Public Transportation

ABSTRACT

A mobile device such as a mobile phone, smart phone, personal music player, handheld game device and the like that is configured to be location-aware through GPS (Global Positioning System), cell tower positioning, or other means of determining location, is provided with a public transportation selector functionality that interfaces with one or more on-line public transportation schedule services. The public transportation selector passes the location of a user of the mobile device, the user&#39;s destination, and the targeted arrival time to the schedule services which responsively return information including, for example, station/stop location information, route identifier, departure and arrival times, and fare costs. The public transportation selector aggregates schedule information provided by the services for presentation to the user through a user interface on the mobile device. The user can then select the desired public transportation option and be provided with directions to the appropriate station or stop.

BACKGROUND

People often rely on public transportation in many parts of the world asa safe, efficient, and cost effective way to travel in increasinglycrowded urban and suburban areas. But it can often be difficult toquickly identify the available means of public transportation,particularly, for example, in unfamiliar geographic areas, or at timesof the day that are not typical or usual for the traveler. Even if thetraveler can find a bus or subway station, it is not alwaysstraightforward to determine which route to take that will ensure thatthe traveler will arrive at the desired destination at the desired time.

SUMMARY

A mobile device such as a mobile phone, smart phone, personal musicplayer, handheld game device, and the like, that is configured to belocation-aware through GPS (Global Positioning System), cell towerpositioning, or other means of determining location, is provided with apublic transportation selector functionality (e.g., implemented using asoftware application) that interfaces with one or more on-line publictransportation schedule services. The public transportation selectorpasses the location of a user of the mobile device, the user'sdestination, and the targeted arrival time to the schedule serviceswhich responsively return information including, for example,station/stop location information, route identifier (e.g., bus number,subway line, etc.), departure and arrival times, and fare costs relatingto the available transportation options which may include bus, train,subway, ferry, and other forms of public transportation. The publictransportation selector aggregates schedule information provided by theservices for presentation to the user through a user interface (“UI”) onthe mobile device. The user can then select the desired publictransportation option and be provided with directions to the appropriatestation or stop.

In various illustrative examples, the user inputs a desired destinationthrough the UI. Alternatively, the destination may be identifiedautomatically through an interface with the user's scheduling tool(e.g., appointment book or calendar application) on the mobile device.Actual transit times may be collected and stored in a route database sothat the public transportation selector may optimize the transportationoptions presented to the user. Published route information from thepublic transportation schedule services, stored user preferences,appointment and contact data, and/or user profile information may alsobe utilized when performing the optimization. In addition, the publictransportation selector may utilize such information when generatingsuggested points of interest that the user may wish to visit on the wayto the station or along the route from the station to the destination.The public transportation selector may also be configured with afunctionality to enable the user to pay for the public transportationfare or make a reservation right from the mobile device.

Advantageously, the present location-aware selection of publictransportation provides users with an easy to use way to find publictransportation that meets their needs. The interfaces between the publictransportation selector and other functionalities on the mobile device,such as scheduling applications and user preferences/profile datastores, further enable effective route selection and optimizationoptions to be automatically and transparently generated for the user.The user can thus effectively utilize public transportation in a waythat suits their particular needs and preferences.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an illustrative public transportation environment in whichthe present location-aware selection of public transportation may bepracticed;

FIG. 2 is a simplified functional block diagram of a transportationapplication that is configured to run on a mobile device;

FIG. 3 shows an illustrative communication flow between thetransportation application and a transportation schedule service in anexample usage scenario;

FIG. 4 shows an illustrative communication flow between thetransportation application and the mobile device user in an exampleusage scenario; and

FIG. 5 shows an illustrative public transportation route that isannotated with points of interest.

Like reference numerals indicate like elements in the drawings.

DETAILED DESCRIPTION

FIG. 1 shows an illustrative public transportation environment 100 inwhich the present location-aware selection of public transportation maybe practiced. In the environment 100, a user 102 employs alocation-aware mobile device 105 such as a mobile phone, smart phone,PDA (personal data assistant), handheld game device, handheld computer,pocket PC (personal computer), portable media player such as those whichcan play MP3 (Moving Pictures Expert Group, MPEG-1, audio layer 3)files, or device which integrates several of such functions. It is notedthat these types of mobile devices are intended to be illustrative andthat other types of mobile devices may also be used in the presentarrangement as may be required to meet the needs of a particularimplementation.

The mobile device 105 may be configured with location-awareness using avariety of conventional techniques. These may include, for example, theuse of GPS in which location is determined through a triangulationcalculation based on signals from a network of satellites (asrepresentatively indicated by reference numeral 112).

Alternatively, cell tower positioning may be utilized to approximate theposition of the mobile device 105 by comparing the relative signalstrength between the mobile device and multiple antenna towers (asrepresentatively indicated by reference numeral 116). While cell towerpositioning is a less accurate technology compared with GPS, it maystill provide sufficient accuracy in many cases to providelocation-awareness to the mobile device 105 in the present application.In addition, cell tower positioning often provides superior locationdetermination compared with GPS when mobile devices are used indoors. Insome implementations, it may be desirable to use both GPS and cell towerpositioning technologies. It is emphasized that the foregoing examplesof location-awareness are intended to be illustrative only and thatother methodologies may also be utilized as may be required to meet theneeds of a particular implementation.

The mobile device 105 is further configured for wireless communicationusing a mobile data network to gain access to resources that are locatedon a public network such as the Internet 120. The mobile data networkcould be arranged, for example, in accordance with GPRS (General PacketRadio Service), EVDO (Evolution Data Optimized), UMTS (Universal MobileTelecommunications System), or other known arrangements. In alternativeimplementations, the resources may be accessed via private networkinfrastructure such as VPN (virtual private networks).

The Internet-accessible resources include public transportation scheduleservices 124 which include, in this illustrative example, a bus scheduleservice 124 ₁, a train schedule service 124 ₂, and transportationschedule service 124 _(N) named “other” which is intended to represent aservice that covers other forms of public transportation. These include,for example (but are not necessarily limited to) trains, light railconveyances, subway, trams, trolleys, streetcars, ferries, water taxis,and similar types of transportation that may be provided by public orprivate entities for the benefit of the general public.

The transportation services 124 are configured to support databases ofinformation that pertain to their respective type of transportation. So,for example, the bus schedule service 124 ₁ will typically have accessto bus routes, schedules, fare, and other information (e.g., generalpassenger, station, or accessibility information, the availability ofspecial services, etc.) for one or more bus lines or providers that mayservice a particular geographic region. Such data can be populated intothe databases using any of a variety of conventional methods includingmanual and automated data capture methods using schedule informationthat is typically published by the transportation provider.

It is noted that while separate schedule services 124 are shown in FIG.1, in some implementations, the services may be combined orconsolidated. For example, a single schedule service 124 might be usedto provide information about more than one type of transportation. Thereis no requirement that schedule services be implemented on a one-to-onebasis with the available types of transportation.

The location-aware mobile device 105 can interact with thetransportation services 124 to receive schedule, public transportationstation or stop locations, route identifiers (e.g., bus number, subwayline, ferry dock number, etc.), fare or ticket price, and otherinformation from the services in response to a query or request from thedevice. The query will typically specify the location of the user, theuser's destination, and the desired time of arrival. The mobile device105 can thus receive, for example, a list of transit options, directionsto route the user 102 (as indicated by reference numeral 130) to thestation or stop 136 of a train, bus, subway, etc., that is near to thelocation of the user 102 and identify the appropriate line, number, orroute that can take him or her to the destination in the desiredtimeframe, and fare information.

More specifically, as shown in FIG. 2, the mobile device 105 includes atransportation application 202 that is configured to interact with oneor more of the transportation services 124 to enable the present publictransportation selection feature set when run on the device. Typically,the transportation application 202 will run as software code on themobile device 105, although it can also be implemented using firmwareand/or hardware-based solution, or combinations of software, firmware,and hardware in some implementations. In addition, the transportationapplication 105 can be supported by the mobile device 105 under various“software as services” models where all or a portion of the applicationruns on a remote server.

In this example, the transportation application is architected, as shownin FIG. 2, using a number of components. However, it is emphasized thatthe particular components shown in FIG. 2 and described below areintended to be illustrative and that the functionality supported thereinmay be provided by components or modules other than those shown, or beallocated among the components in a different manner than thatdescribed.

The transportation application 202 includes a public transportationselector 209 that is configured to provide the core location-awareselection functionality. The user 102 interacts with the publictransportation selector through a UI 211, typically through support of agraphical display and a means for input capture. A location module 215provides the interface to the location-aware hardware in the mobiledevice such as GPS or cell tower positioning components.

A group of service adapters 223 provide interfaces 225 over the wirelessdata network to the respective schedule services 124 on the Internet 120(FIG. 1). In particular, as shown, a service adapter (bus) 223 ₁provides an interface 225 ₁ to the bus schedule service 124 ₁.Similarly, the service adapter (train) 223 ₂ provides an interface 225 ₂to the train schedule service 124 ₂. And, the service adapter (other)223 _(N) provides an interface 225 _(N) to the other schedule service124 _(N). The particular number and type of service adapters 223utilized in any given implementation can vary from that shown in FIG. 2.In addition, service adapters can be created by third parties (i.e.,parties other than a mobile device maker, transportation applicationprovider, or schedule service provider) and utilized to enhance thecapabilities of the present arrangement in some applications.

A route database 230 is utilized locally on the mobile device 105 tostore route information that is downloaded from the schedule services aswell as to provide a store for actual transit times experienced by theuser 102 when following a particular transportation route.Alternatively, the actual transit times can be collected for other usersfor a variety of routes at some central collection point (such as a dataserver) and then uploaded to the route database. As described in moredetail below, such historical transit times can be utilized by thepublic transportation selector, alone or in combination with other data,as part of the optimization of transportation options that are presentedto the user 102 through the UI 211.

A scheduling module 235 is configured to provide an interface to theuser's scheduling or appointment application that may be running on themobile device 105. For example, the user may be running an instance ofMicrosoft Outlook® Mobile on the mobile device 105 to manage e-mail,calendars, contacts, and tasks. The scheduling module 235 enables thepublic transportation selector 209 to obtain information about theuser's schedule and appointments. Typically the user will be providedwith an opportunity to synchronize such information with thetransportation application. Knowledge of the user's schedule andappointments, including for example, the time and location of suchappointments, can assist the public transportation selector 209 totransparently (i.e., without requiring an affirmative or explicit actionon the part of the user 102) recognize a need for the user to be at aparticular place at a particular time. The public transportationselector 209 can then provide an appropriate set of transportationoptions that are responsive to such need.

In a similar manner as with the scheduling module, a user profile 241may be optionally utilized (as indicated by its dashed outline) tofurther enhance the public transportation selector's ability to providetransportation options to the user 102 that suits the user's needs. Asabove, the user 102 will typically be provided with an opportunity toopt in to the collection of data regarding the user's usage of themobile device 105.

Various techniques and heuristics can be employed to infer a userpreference from collected profile data. In some cases, user preferencesmay be explicitly solicited by the transportation application, or may beset, modified or updated by the user 102. For example, if the userprofile or preference indicates that buses are most preferred by theuser, and subways least preferred, the public transportation selector209 can act appropriately when providing transportation options for agiven usage scenario.

Also optionally utilized in the transportation application 202 is thepayment module 248. This module can be used in those implementationswhere infrastructure is in place to facilitate secure paymenttransactions to the transportation providers (either directly or viathird party service) using the mobile device 105. Such transactions canutilize a pre-payment system or be tied to a traditional credit card,for example. Alternatively, the use of other known electronic paymentsystems such as near field communications (“NFC”) may also befacilitated by the payment module 248 using the mobile device 105 as adelivery mechanism. In some implementations, it may be desirable tocollect a fee for facilitating the ticket purchase transaction using themobile device 105. The recipient of the fee may be one of the scheduleservice providers, or a third party, for example.

Turning now to FIG. 3, an illustrative flow of communications betweenthe transportation application 202 and a schedule service 124 is shownfor an example usage scenario. The scenario starts by a service adapter223 in the transportation application 202 registering with itscorresponding schedule service 124 (as indicated by reference numeral310). Thus, for example, the service adapter (bus) 2231 will registerwith the bus schedule service 1241 and so forth. The service adapter 223will typically perform the registration using a simple handshake withthe service 124 when there is need to pull schedule data or statusupdates about service affecting issues. For example, the user 102 maywork through the UI 211 to explicitly make a request to locate publictransportation. Or, the scheduling module 235 may identify an upcomingappointment at a distant location which the public transportationselector 209 uses as an automatic trigger to initiate the registrationin a manner that is transparent to the user.

The location module 215 determines the current location of the mobiledevice 105 (and hence the location of the user 102) which is relayed viathe service adapter 223 along with the destination and desired arrivaltime to the schedule service 124 (320). In response, the scheduleservice 124 will return a selection of possible transportation routeswith associated schedules for the particular public transportation typeand the corresponding fee information back to the service adapter 223(330).

The route identifies the starting and destination points and, in mostcases, schedule information that includes published or approximatedeparture and arrival times for each route. The number, line, route, orother identifying information will also be provided (e.g., bus #6, theyellow subway line, ferry slip 3, etc.) Typically, as multiple serviceadapters are used to interface with multiple transportation scheduleservices, the steps of registration, reporting, and information returnare performed with each service adapter and schedule service pair, andthe transportation application 202 may assemble a multi-segment routeout of segments provided by different types of transportation—forexample, a leg of the route by ferry, then by bus, then by subway.Depending upon the particular circumstances, it may be possible for arelatively large amount of information to be passed back from thevarious transportation schedule services 124 to the transportationapplication 202 running on the mobile device 105. That is, there may bemultiple ways for the user 102 to get to a particular destination usingdifferent forms of public transportation that traverse different routes,and within some reasonable interval to the desired arrival time.

Other types of information can also be returned by a schedule service124. While it may vary by implementation, the information may be drawnfrom the information databases supported by the schedule service 124 andinclude general passenger, station, or accessibility information, theavailability of special services, etc., as noted above.

The public transportation selector 209 is responsible for taking theroute and schedule information returned from the schedule services 124and presenting it to the user through the UI 211. In some cases, asnoted above, the information can aggregate a multi-segment route usingdifferent public transportation types. FIG. 4 shows an illustrative flowof communications between the transportation application 202 and theuser 102 for the example usage scenario shown in FIG. 3 and describedabove.

Generally in most implementations it will be desirable for the publictransportation selector 209 to apply rules or heuristics to sort or rankorder the returned information. In this way the public transportationselector 209 can optimize the routes and schedules to present the user102 with a select subset of all the available transportation options (asindicated by reference numeral 410). Alternatively, the optimization canbe performed remotely by one of the schedule services 124 or by anotherremote service. Optimization may also be shared between the locallyrunning transportation application and a remote service.

The optimization techniques may vary by implementation. In some cases,the public transportation selector 209 will consider locally storedinformation such as historic transit times from the route database 230,or profile and/or user preferences from the user profile 241.

With the route database 230, the stored historical transit times for aparticular route (or any other information provided by the user) enablethe public transportation selector 209 to determine the likelihood of atransportation option getting the user 102 to the destination by thedesired time. Thus, for example, while published schedule informationmay indicate that a bus running on a city's west side route is supposedto arrive at the central station at 2 pm, the historical data may showthat this bus typically runs late.

The historical transit time information may also be particularly usefulfor public transportation that does not provide published departure andarrival times. With some subway lines, for example, subway cars arriveat each station on a periodic basis but not at a set time. In this case,the historical transit time information will typically help the publictransportation selector 209 in determining whether that particularsubway route is an appropriate option to present to the user 102 andfurther enable the public transportation selector to provide approximatedeparture and/or arrival times.

The public transportation selector 209 may use data from the userprofile 241 to optimize route selection by filtering or weightingtransportation options based on explicitly generated user preferences orpreferences that may be inferred from the collected user profile data.Thus, transportation by subway may be considered a more optimizedsolution for the user 102 in light of the profile or preference, even ifa bus stop, for example, may be physically closer to the user's currentlocation at the time of the query. Accordingly, the publictransportation selector 209 will typically rank order subway routes overbus routes when presenting transportation options to the user 102 whenit is determined that subways are the user's preferred type oftransportation.

When presented with the transportation options, the user 102 can workthrough the UI to pick an option that is desired and meets the user'sneeds (420). Responsively to the user's selection of the transportationoption, station route information (i.e., direction) will be providedthrough the UI 211 (430). The user 102 may also be optionally presentedwith the ability to make an electronic payment for the fare associatedwith the selected transportation option, or make a reservation (440). Inthis case, the functionality from the payment module 248 will typicallybe invoked.

As the user 102 makes the trip using the selected transportation option,the actual transit time associated with the route will be collected sothat the route database 230 can be updated. The transit time can becalculated once the location module 215 indicates that the mobile device105 (and hence the user 102 as well) has arrived at the destination.

Additional value-added features may also be advantageously implementedusing the present location-aware public transportation selectionarrangement. As shown in FIG. 5, the public transportation selector 209can annotate the station route information 530 (i.e., the directions tothe station or stop 136) with various points of interest 535_(1, 2 . . . N) along the route. The points of interest 535 may vary byimplementation and may include, for example, friends of the user 102,retail stores, museums, restaurants, and the like. The points ofinterest 535 can be automatically generated by the public transportationselector 209 using locally available data. Alternatively, the points ofinterest 535 can be generated remotely using an external service.

So, for example, the public transportation selector 209 might determinefrom the user's contact list that is available from the schedulingmodule 235 that a friend or acquaintance of the user 102 resides orworks near the route to the station 136. If so, the UI 211 can includean annotation with the station route information 530 that there is anopportunity for a visit with the friend or acquaintance.

If the current time is close to a meal time, the public transportationselector 209 may also include an annotation with the station routeinformation 530 that a restaurant that the user 102 may like is alongthe route to the station 136. The public transportation selector 209 mayuse data from the user profile 241 when making this annotation.

If the scheduling module 235 indicates that the user 102 has created atask to purchase a gift, for example, for a friend's upcoming birthday,the public transportation selector 209 can make an annotation that anappropriate retail store is along the route to the station 136.

Data from the user profile 241 or scheduling module 235 may be used in asimilar manner as in the examples above to generate annotations aboutother points of interest for the user 102 (e.g., museums, memorials,historical sites, recreation and entertainment, and the like). Shouldthe user 102 wish to take time to accommodate a point of interest, thepublic transportation selector 209 can re-query the schedule services124, if necessary and then determine additional transportation optionsthat may be presented to the user 102 that take into account theadditional time.

The constellation of potential points of interest 535 can be storedlocally in the mobile device 105 and be periodically updated throughinteraction with a remote service, for example, so that the annotationsreflect current and valid information. Alternatively, the points ofinterest 535 can be dynamically received in real time by an appropriatequery to the remote service.

The public transportation selector 209 can also be configured togenerate annotations that are applicable to the route taken by theselected mode of public transportation. As shown in FIG. 5, thetransportation route information 541 may include annotations of variouspoints of interest 547 _(1, 2 . . . N) that the user 102 may wish tovisit along the transportation route to the destination 550. The publictransportation selector 209 can utilize a similar methodology, asdescribed above for annotating station route information, whengenerating annotations for points of interest 547 to the transportationroute information 541. That is, the public transportation selector 209can take into account locally available information such as data fromthe scheduling module 235 and user profile 241 when making theannotation for the points of interest 547. And, as with the exampleabove, the public transportation selector 209 can re-query the scheduleservices 124, if necessary, and determine additional transportationoptions that may be presented to the user 102 that take into account theadditional time required to accommodate a point of interest 547.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computer-readable medium not comprising apropagated data signal containing instructions which, when executed byone or more processors on a mobile device associated with a user,implement a transportation application for providing publictransportation options to the user, the transportation applicationcomprising: a service adapter, the service adapter configured to:interface with one or more of a plurality of schedule services; receivepublic transportation information from the one or more respectiveschedule services of the plurality of schedule services in regard to adestination; and store the received public transportation informationfrom the one or more respective schedule services in a route database; apublic transportation selector, the public transportation selectorconfigured to provide a set of transportation options to the user inresponse to a query regarding transportation from a start location to adestination location with a target time of arrival at the destinationlocation, wherein the public transportation selector determines the setof transportation options according to the received publictransportation information; and a user interface, the user interfaceconfigured to present the set of transportation options provided by thepublic transportation selector to the user.
 2. The computer-readablemedium of claim 1, wherein the transportation application furthercomprises a location module that interfaces with location-awarefunctionality disposed in the mobile device, the location moduleidentifying the present location of the mobile phone to the publictransportation selector.
 3. The computer-readable medium of claim 2,wherein the transportation application further comprises a schedulingmodule, the scheduling module configured to interface with schedulingdata having applicability to the user, the scheduling data including atleast one of an appointment, a calendar, a contact, or a task.
 4. Thecomputer-readable medium of claim 3, wherein the scheduling module isfurther configured to generate the query according to the schedulingdata having applicability to the user.
 5. The computer-readable mediumof claim 3, wherein the transportation application further comprises auser profile configured for storing profile data that is collected aboutthe user.
 6. The computer-readable medium of claim 5, wherein at leastone of the route database, scheduling module, or user profile is used bythe public transportation selector for filtering transportationinformation from a schedule service of the plurality of scheduleservices.
 7. The computer-readable medium of claim 1, wherein thelocation functionality is one of a global positioning system (GPS) or acell tower positioning functionality.
 8. The computer-readable medium ofclaim 1, wherein the transportation application further comprises apayment module, the payment module being configured to facilitate anelectronic payment of a fare associated with a public transportationroute.
 9. The computer-readable medium of claim 8, wherein the publictransportation selector applies one or more heuristics to theinformation from the plurality of schedule services to optimize thepublic transportation options presented to the user through the userinterface.
 10. A method, configured for execution on a mobile device,for identifying and presenting public transportation information to auser associated with the mobile device, the method comprising the stepsof: obtaining public transportation information of one or more types ofpublic transportation that are available for use within a givengeographic region storing the public transportation information in aroute database; receiving a query, the query requesting routeinformation for navigating to a target destination to arrive at a targetarrival time at the target destination; identifying one or moretransportation options of the public transportation information from theroute database, the one or more transportation options for navigation tothe target destination to arrive at the target arrival time at thetarget destination; and presenting the one or more transportationoptions to the user via the mobile device.
 11. The method of claim 10further comprising: receiving a selection of a first transportationoption of the one or more transportation options for navigation to thetarget destination to arrive at the target arrival time at the targetdestination; transacting a purchase between a public transportationprovider associated with the first transportation option and the userassociated with the mobile device.
 12. The method of claim 10, whereineach of the one or more transportation options for navigation to thetarget destination to arrive at the target arrival time at the targetdestination include at least one public transportation service.
 13. Themethod of claim 12, wherein the least one public transportation servicecomprise one of a bus, a rail, a light rail, a subway, a trolley, astreetcar, a tram, a ferry, or a water taxi.
 14. The method of claim 10,wherein the public transportation information is obtained by the mobiledevice from a plurality of schedule services via a wireless datanetwork.
 15. The method of claim 10, wherein identifying one or moretransportation options of the public transportation information from theroute database comprises identifying one or more transportation optionsof the public transportation information from the route database and asource information, the one or more transportation options fornavigation to the target destination from the source location to arriveat the target arrival time at the target destination.
 16. The method ofclaim 15 further comprising obtaining a present location information ofthe mobile device from a location-aware functionality disposed in themobile device, wherein the present location is the source location. 17.The method of claim 15, further comprising receiving the source locationfrom the user associated with the mobile device.
 18. The method of claim10 further comprising obtaining scheduling data having applicability tothe user of the mobile device, the scheduling data including at leastone of an appointment, a calendar, a contact, or a task.
 19. The methodof claim 18, wherein the query is automatically generated according tothe scheduling data having applicability to the user.
 20. A mobiledevice associated with a user and configured to provide transportationinformation to the user, the mobile device comprising: a location moduledisposed in the mobile device for determining location information ofthe mobile device; a route database, the route database configured tostore public transportation information from one or more scheduleservices; and a transportation application, the transportationapplication comprising: one or more of service adapters, wherein each ofthe one or more service adapters interfaces over a network with at leastone schedule service of a plurality of schedule services to receivepublic transportation information from the at least one schedule serviceof the plurality of schedule services, and stores the publictransportation information in the route database; and a publictransportation selector, wherein the public transportation selectorprovides transportation options for navigating to a target destinationto arrive at a target time according to the public transportationinformation in the route database in response to a query identifying thetarget destination and the target time.